Data streaming system and method

ABSTRACT

A data streaming system and method are described. A server ( 10 ) is arranged to stream one of a plurality of encoded data streams to a client ( 40, 50, 60 ). Each of the plurality of data streams is an independent representation of a common data source encoded at a different resolution to the other of the plurality of data streams. The server ( 10 ) comprises a transmitter ( 100 ) and a first buffer ( 120 ). The transmitter is arranged to transmit data packets of the encoded data stream to the client ( 40, 50, 60 ) via the first buffer ( 120 ). The transmitter ( 100 ) is arranged to monitor the content of the first buffer ( 120 ) and switch to transmit another of the plurality of data streams in the event that predetermined criteria are detected from the first buffer ( 120 ).

The present invention relates to a system and method suitable forstreaming audio and video content over IP (Internet Protocol) networks.In particular, the present invention is suitable for use where theavailable bit rate is inherently variable due to physical networkcharacteristics and/or contention with other traffic. For example, thepresent invention is suitable for multimedia streaming to mobilehandheld terminals, such as PDAs (Personal Digital Assistants) via GPRS(General Packet Radio Service) or 3G networks.

New data network access technologies such as cable and ADSL (AsymmetricDigital Subscriber Line) modems, together with advances in compressionand the availability of free client software are driving the growth ofvideo streaming over the Internet. The use of this technology is growingexponentially, possibly doubling in size every six months, with anestimated half a billion streams being served in 2000. However, userperception of Internet streaming is still coloured by experiences ofcongestion and large start-up delays.

Current IP networks are not well suited to the streaming of videocontent as they exhibit packet loss, delay and jitter (delay variation),as well as variable achievable throughput, all of which can detract fromthe end-users enjoyment of the multimedia content.

Real-time video applications require all packets to arrive in a timelymanner. If packets are lost, then the synchronisation between encoderand decoder is broken, and errors propagate through the rendered videofor some time. If packets are excessively delayed, they become uselessto the decoder, which must operate in real-time, and are treated aslost. Packet loss, and its visual effect on the rendered video, isparticularly significant in predictive video coding systems, such asH.263. The effect of packet loss can be reduced, but not eliminated, byintroducing error protection into the video stream. It has been foundthat such resilience techniques can only minimise, rather thaneliminate, the effect of packet loss.

In the case of a sustained packet loss, indicating a long-term drop inthroughput, the streaming system needs to be able to reduce its longterm requirements. This commonly means that the bit-rate of the streamedmedia must be reduced.

Standard compression technologies, such as H.263 and MPEG-4, can bemanaged to provide a multimedia source that is capable of changing itsencoding rate dynamically. A video source having such properties isdescribed herein as an elastic source, i.e. one that is capable ofadapting to long-term variations in network throughput. This is commonlyachieved by providing a continuously adaptive video bit-rate. This ispossible because unlike audio codecs, video compression standards do notspecify an absolute operating bit-rate.

Video streaming systems may be designed to provide an encoded streamwith varying bit rate, where the bit rate adapts, in response to clientfeedback, instantly to the available network bandwidth. Such a systemcould be made to be network-friendly, by controlling the transmissionrate such that it reduces rapidly in the case, of packet loss, andincreases slowly at other times.

However, this solution is not practical for two reasons. Firstly,real-time video encoding usually requires a large amount of processingpower, thus preventing such a solution from scaling to support manyusers. Secondly, the end-user perception of the overall quality will beadversely affected by rapid variations in instantaneous quality.

For uni-directional streaming applications, the delay between the senderand receiver is only perceptible at start-up. Therefore, commontechniques trade delay for packet loss and jitter. Provided the averagethroughput requirements of the video stream match the average availablebandwidth the receiver buffer size can be dimensioned to contain theexpected variation in delay.

Market-leading streaming systems are believed to use significantclient-side buffering to reduce the effects of jitter that may beencountered in the Internet. While this helps, it also introduces largestart-up delays, typically between 5 and 30 seconds, as the bufferfills. These systems also include technologies that allow the client toadapt to variations in available bandwidth. Although the details ofthese techniques are not publicly available, it is suspected that theygenerally use multi-data rate encoding within single files (SNRscalability), and intelligent transmission techniques such asserver-side reduction of the video picture rate to maintain audioquality. Such large amounts of buffering could conceivably allow asignificant proportion of packets to be resent, although thesere-transmissions themselves are subject to the same networkcharacteristics. The decision to resend lost data is conditional on thisand several other factors. Such techniques are generally only applicableto unicast transmissions. Multicast transmission systems are typicallybetter served by forward error correction or receiver-based scalabilitysuch as RLM and RLC. S. McCanne, ‘Receiver driven layered multicast’,Proceedings of SIGCOMM 96, Stanford. Calif. August 1996. L. Vicisano, L.Rizzo and J. Crowcroft, ‘TCP-like congestion control for layeredmulticast data transfer’, Infocom '98.

The use of a buffer as described above allows a system to overcomepacket loss and jitter. However, it does not overcome the problem ofthere being insufficient bit rate available from the network. If thelong term average bit rate requirements of the video material exceedsthe average bit rate available from the network, the client buffer willeventually be drained and the video renderer will stop until the bufferis refilled. The degree of mismatch between available network bit rateand the rate at which the content was encoded determines the frequencyof pausing to refill the buffer.

As described above, most video compression algorithms, including H.263and MPEG-4, can be implemented to provide a continuously adaptive bitrate. However, once video and audio have been compressed, they becomeinelastic, and need to be transmitted at the encoded bit-rate.

Whilst network jitter and short term variations in network throughputcan be absorbed by operating a buffer at the receiver, elasticity isachieved only when long-term variations in the network throughput canalso be absorbed.

Layered encoding is a well-known technique for creating elastic videosources. Layered video compression uses a hierarchical coding scheme, inwhich quality at the receiver is enhanced by the reception and decodingof higher layers, which are sequentially added to the baserepresentation. At any time, each client may receive any number of thesevideo layers, depending on their current network connectivity to thesource. In its simplest implementation, this provides a coarse-grainadaptation to network conditions, which is advantageous in multicastscenarios. Layered video compression has also been combined withbuffering at the client, to add fine-grain adaptation to networkconditions. However, it has been shown that layered encoding techniquesare inefficient, and will typically require significantly moreprocessing at the client which causes particular problems when dealingwith mobile devices, which are likely to have reduced processingcapability.

Transcoding is another well-known technique for creating elastic videosources. It has been shown that video transcoding can be designed tohave much lower computational complexity than video encoding. However,the computational complexity is not negligible, and so would not lead toa scalable architecture for video streaming.

According to one aspect of the present invention, there is provided adata streaming system comprising a server arranged to stream one of aplurality of encoded data streams to a client, each of the plurality ofdata streams being an independent representation of a common data sourceencoded at a different resolution to the other of the plurality of datastreams, the server comprising a transmitter and a first buffer, thetransmitter being arranged to transmit data packets of the encoded datastream to the client via the first buffer, wherein the transmitter isarranged to monitor the content of the first buffer and switch totransmit another of the plurality of data streams in the event thatpredetermined criteria are detected from the first buffer.

Some of the key attributes of the overall system are:

-   -   varying the transmission rate in a network-friendly manner;    -   decoupling of the transmission rate from the media encoding        rate;    -   building up a buffer of data at the client without incurring a        start-up delay;    -   smoothing short term variations in network throughput by use of        client buffering;    -   adjusting long-term average bandwidth requirements to match the        available resources in the network by switching between        multimedia streams encoded at different bit rates; and,    -   providing resilience to packet loss by selectively        retransmitting lost packets, without affecting the quality        perceived by the user, by use of client buffering.

The present invention permits scaling the transmission bit rate of thecompressed video in dependence on changing network conditions.

In the present invention, a produced audio-visual stream does not haveto be transmitted at a single fixed bit rate, thus allowing transmissionat whatever rate the network instantaneously supports. Resilience totransmission losses is provided by building a buffer of data at thereceiver, to allow time for lost data to be retransmitted before it isneeded for decoding and presentation.

At any one time, only one video stream and one audio stream from ahierarchy of such streams are transmitted to a client. This isimplemented in the form of a combination of so called “simulcastswitching” for coarse-grain adaptability, and transmission ratevariation for fine-grain adaptation.

The system has been shown to perform well over a GPRS network, makinggood use of the available network bandwidth, to provide satisfactorymultimedia quality.

The system has been designed to overcome the characteristics of IPnetworks, and in particular mobile IP networks, to provide users withmultimedia of consistent quality with minimal start-up delay.

The transmitter may be arranged to determine the amount of data bufferedat the client from the content of the first buffer, wherein thepredetermined criteria include a predetermined level of data determinedto be buffered at the client. A data packet may be removed from thefirst buffer upon acknowledgement by the client of receipt of thepacket. The transmitter may be arranged to determine the amount of databuffered at the client in dependence on the latest data packet removedfrom the first buffer and on an estimation of number of packets decodedby the client.

The first buffer may include a mirror buffer storing data on packets inthe first buffer, the transmitter being arranged to monitor the contentof the first buffer using the data in the mirror buffer.

Data packets may be transmitted to the client using an extended TPKTprotocol, the data packets including a header containing a decodingtimestamp and a data stream identifier.

The system may further comprise a plurality of transmitters, eachcommunicating with a respective client via a respective first buffer totransmit one of the plurality of data streams determined in dependenceon respective predetermined criteria.

The data stream may be encoded video data.

The transmitter may be arranged to multiplex audio packets and videopackets within the transmission of data packets. Neighbouring audio andvideo packets may represent audio and video information that is intendedfor representation at substantially the same time.

The data stream may be encoded audio data.

The resolution may be an encoding bit rate of the data.

The server may include an encoder arranged to accept a data feed andencode the data feed into the plurality of encoded data streams.

The system may further comprise a plurality of buffers, wherein theencoder is arranged to output each encoded data stream into a respectiveone of the plurality of buffers, the transmitter being arranged toobtain data packets for a respective data stream from its respective oneof the plurality of buffers.

The server may include a file source storing the plurality of encodeddata streams.

According to another aspect of the present invention, there is provideda data streaming system comprising a client and a server, the serverbeing arranged to stream one of a plurality of encoded data streams tothe client, each of the plurality of data streams being an independentrepresentation of a common data source encoded at a different resolutionto the other of the plurality of data streams, the server comprising atransmitter and a first buffer and the client including a receivingbuffer, wherein the transmitter is arranged to transmit data packets ofthe encoded data stream to the client via the first buffer, wherein theclient is arranged to store received data packets in the receivingbuffer and to acknowledge receipt to the server, wherein the transmitteris arranged to delete packets from the first buffer when anacknowledgement receipt is received, the server being arranged to switchto another of the plurality of data streams in the event thatpredetermined criteria are satisfied, the predetermined criteriacomprising analysis on content of the first buffer.

The packets may include packet sequence data, the client being arrangedto request retransmission of non-received packets based on the sequencedata, the server being arranged to retransmit a packet from the firstbuffer upon receipt of a retransmission request.

According to a further aspect of the present invention, there isprovided a method of streaming one of a plurality of encoded datastreams to a client, each of the plurality of data streams being anindependent representation of a common data source encoded at adifferent resolution to the other of the plurality of data streams, themethod comprising the steps of:

-   -   transmitting data packets of the encoded data stream to the        client via a first buffer;    -   monitoring the content of the first buffer; and,    -   switching to transmit another of the plurality of data streams        in the event that predetermined criteria are detected from the        first buffer.

The plurality of data streams may each be encoded at a different bitrate, the method further comprising the step of initially transmittingdata packets of the lowest bit rate data stream.

The predetermined criteria may include an amount of data determined tobe buffered at client.

The predetermined criteria may include one or more network throughputthresholds.

Network throughput may be calculated by the steps of:

-   -   counting the number of bytes passed to the first buffer;    -   subtracting the counted number of bytes from the size of the        first buffer, and,    -   dividing the result by the time since the start of transmission.

The method may further comprise the step of measuring network throughputover more than one interval to determine throughput variation.

The predetermined criteria may include determination of networkthroughput sufficient to sustain the other of the plurality of the datastreams.

The method may further comprise the step transmitting data at a maximumrate irrespective of an amount of data buffered at the client, whereinthe predetermined criteria include network throughput determined at themaximum rate.

The data streams may be encoded as a series of pictures predictivelyencoded in dependence on the previous pictures in the data stream, thedata streams including quantised source access pictures interspersed atpredetermined periods in the picture series, wherein the method ofencoding the quantised source access pictures including the steps of:

-   -   encoding picture as a predicted picture; and,    -   if no information about an area of a picture is indicated in the        encoded predicted picture, setting the quantiser index to a fine        quantisation value when encoding as a quantised source access        picture.

Examples of the present invention will now be described in detail, withreference to the accompanying Figures, in which:

FIG. 1 is a schematic diagram of an audio-visual data streaming systemin accordance with an embodiment of the present invention;

FIG. 2 is a schematic diagram of a video encoding hierarchy used in thesystem of FIG. 1.

FIG. 3 is a schematic diagram of a video encoding architecture thatallows mismatch free switching between video streams to be achieved.

FIG. 4 is a schematic diagram of a client-server architecture suitablefor use in the system of FIG. 1;

FIGS. 5 a and 5 b are, respectively, diagrams illustrating standard TKPTtransport packet structure and a variation of that structure implementedfor the present invention; and,

FIGS. 6 a-6 c are schematic diagrams illustrating aspects of a datastructure comprising an audio-visual data stream suitable for storingdata for use in the present invention.

FIG. 1 is a schematic diagram of an audio-visual data streaming systemin accordance with an embodiment of the present invention.

The server 10 receives encoded multimedia content either directly froman encoder 20 or from a file 30, and serves this content to one or moreclients 40-60. The server 10 scales to support many clients 40-60accessing many pieces of content independently as it performs littleprocessing, just selecting packets for onward transmission. No encodingor transcoding of media is performed in the server 10.

In principle, the server 10 operates in the same way for both livestreams, provided from the encoder 20, and for pre-encoded streams fromthe file 30. In this particular embodiment, streaming of live media isdescribed. Differences in streaming media from pre-encoded files arediscussed in later embodiments.

The server 10 includes a number of circular buffers 70-90. For eachclient 40-60 there is one instance of a packet transmitter 100. Thepacket transmitter 100 determines when and from which buffer 70-90 thenext packet is read, reads the chosen packet and sends it to therespective client over a network connection 110.

A semi-reliable network connection 110 is required from the server 10 toeach respective client 40-60 to ensure that almost all packets sent arereceived, therefore minimising disturbances to user-perceived quality.Buffers (120, 130) are therefore used at the respective ends of thenetwork connection 110 to allow retransmissions of lost packets. Thenetwork connection 110 is also desired to be network friendly, that is,to allow the bit rate used to be increased when congestion is notexperienced, and to be drastically reduced when congestion occurs.

Whilst the system components are illustrated and described as acombination of integrated and separate components, it will beappreciated that different configurations could be used. For example, anexternal encoder 20 and/or file store 30 could be used. Equally, thebuffers 130 are likely to be integral to the client devices 40-60.

FIG. 2 is a schematic diagram of a video encoding hierarchy used in thesystem of FIG. 1. The encoder 20 encodes live or stored multimediacontent into an elastic encoded representation. Audio is encoded at lowbit rate into a single encoded bit stream, and hence is in itselfinelastic. However, as audio typically requires a smaller bit rate thanvideo, provided the video is encoded in an elastic fashion, then thecombined encoding of audio and video can be considered to be elastic.

Audio is encoded using the AMR (Adaptive Multi-Rate) encoder at 4.8kbit/s. Video is encoded into an elastic representation. In a mannersimilar to layering, the encoder 20 creates a hierarchy of independentvideo streams. Instead of building this hierarchy by making each streamdependent on all streams lower in the hierarchy, each stream is encodedindependently. Such a hierarchy is well-known, being referred to as‘simulcast’.

Although audio data has been described as being encoded using a low bitrate AMR scheme, other AMR encoding rates, and other encoding standardssuch as MP3, could also be supported. Encoded audio at various ratescould be organised in a hierarchy of independent streams in a similarmanner to that described below for video, but with the simplification ofswitching between encoded representations from the fact that each audioframe is typically coded independently.

The video hierarchy, created using an extension to the ITU-T standardH.263, includes an intra stream 200, to allow random access to videostreams, and one or more play streams 210 a, 210 b, for ordinary viewingof the content. Each play stream 210 a, 210 b is encoded at a differentbit rate, thus allowing a given client 40-60 to receive at a rateappropriate for its current network connection 110 to the server 10. Thehierarchy also contains switching streams 220, 230, 240 which allowswitching from the intra stream 200 to the lowest rate play stream 210a, and between play streams.

Since the encoding algorithms employ motion-compensated prediction,switching between bitstreams at arbitrary points in a play stream,although possible, would lead to visual artifacts due to the mismatchbetween the reconstructed frames at the same time instant of differentbit streams. The visual artifacts will further propagate in time.

In current video encoding standards, perfect (mismatch-free) switchingbetween bit streams is possible only at the positions where the futureframes/regions does not use any information previous to the currentswitching location, i.e., at access pictures. Furthermore, by placingaccess pictures at fixed (e.g. 1 sec) intervals, VCR functionalities,such as random access or “Fast Forward” and “Fast Backward” (increasedplayback rate) for streaming video content, are achieved. A user canskip a portion of video and restart playing at any access picturelocation. Similarly, increased playback rate, i.e., fast-forwarding, canbe achieved by transmitting only access pictures.

It is, however, well known that access Pictures require more bits thanthe motion-compensated predicted frames. Thus, the intra stream 200 andswitching streams 220, 230, 240 are used. The main property of switchingstreams is that identical pictures can be obtained even when differentreference frames are used.

The main purpose of the hierarchy is to allow the server 10 to transmita play stream 210 a or 210 b to a client 40-60 to achieve an optimalbalance between building up a buffer of received data at the client40-60 to provide resilience to packet loss and sudden drops in networkthroughput, and providing the best play stream 210 a or 210 b to theclient 40-60 depending on the highest bit rate that its networkconnection 110 instantaneously supports.

The intra stream 200 is a series of intra coded pictures (201, 202) thatare used to provide random access and recovery from severe errorconditions. The play streams 210 a, 210 b include predictively codedpictures (211 a, 212 a, 213 a, 214 a, 215 a; 211 b, 212 b, 213 b, 214 b,215 b) which may be bi-directionally predicted, and may be predictedfrom multiple reference pictures. The play streams 210 a, 210 b alsoinclude periodic access Pictures 216 a, 217 a; 216 b, 217 b. Theswitching streams 220, 230, 240 consist of a series of linking Pictures(221, 222; 231, 232; 241, 242).

The circular buffers 70-92 are designated for each stream type, one foreach intra (70), play (80, 85) and switching (90, 91, 92) stream foreach piece of content

When a client 40 first connects to the server 10, the server 10 locatesan appropriate intra picture (for example, intra picture 201) from thecircular buffer 70 storing the intra stream, and sends this to theclient 40. The server 10 then selects the linking picture (221) toswitch from the intra stream 220 to the play stream 210 a with thelowest encoding bit rate, and then continue to serve from that playstream (213 a onwards).

The transmission of packets to the client 40 is an independent process,with the rate of transmission depending on the state of the network andthe transmission protocol used. However, the intention is that initiallythe transmission rate is greater than the encoding bit rate of the playstream 210 a with the lowest encoding bit rate. This will allow theclient 40 to start decoding and presenting media to the user immediatelyat the point that data is received and decoded, while also allowing theclient 40 to build up excess compressed media data in its decodingbuffer.

At the point where an access picture (such as access picture 217 a inthe above example), the client 40 and/or server 10 may determine that adifferent play stream is more suitable (for example due to increased ordecreased network capacity). In the above example, switching from thelow rate play stream 210 a to the higher rate play stream 210 b isaccomplished by the server 10 transmitting the link picture 232 insteadof access picture 217 a. The link picture 232 links to play streampicture 215 b of the higher rate play stream 210 b allowing the client40 to receive that play stream. Switching to a play stream of decreasedbit rate is accomplished in a similar manner.

Three methods of encoding linking pictures have been investigated. Eachmethod provides different compromises between the accumulation of driftfrom switching, the cost in terms of bit rate of the actual switching,and the impact on the quality of the individual play streams caused byencoding regular pictures of a type that allow drift-free low bit rateswitching.

1. Predictively coded linking pictures

In the first method, linking pictures are generated as Predictedpictures. They are coded in a manner such that when reconstructed theyare similar, in the sense of having for example a small mean squaredifference, to the reconstruction of the simultaneous access picture inthe destination play stream. Access pictures can be coded as Predictedpictures. The number of bits used to encode the linking picturesdetermine how well matched the reconstructed linking picture is to thereconstructed access picture, and hence determines the amount of driftthat would occur as a result of switching. However, drift willaccumulate on each occurrence of switching.

2. Intra coded linking pictures

In the second method, linking pictures are generated as intra pictures.They are coded in a manner such that when reconstructed they aresimilar, in the sense of having for example a small mean squaredifference, to the reconstruction of the simultaneous access picture inthe destination play stream. Access pictures can be coded as Predictedpictures. The number of bits used to encode the linking picturesdetermines how well matched the reconstructed linking picture is to thereconstructed access picture, and hence the amount of drift that wouldoccur as a result of switching. However, for a given amount of mismatch,an intra coded linking picture would usually require many more bits thana predictively coded linking picture. The use of intra coding forlinking pictures prevents the accumulation of drift.

3. Quantised-Source coded linking pictures

In the third method, linking pictures are coded with a technique basedon the concept described in “VCEG-L27, A proposal for SP-frames,submitted by Marta Karczewicz and Ragip Kurceren at theITU-Telecommunications Standardization Sector Video Coding ExpertsGroup's Twelfth Meeting: Eibsee, Germany, 9-12 January, 2001, availableat ftp://standard.pictel.com/video-site/” referred to herein asQuantised-Source pictures.

The encoding architecture for Quantised-Source pictures is shown in FIG.3. The source picture and the motion compensated prediction areindependently quantised in steps 300 and 310 respectively, with the samequantiser index, and transformed, before being subtracted in step 320and variable length encoded in step 330. The reconstructed picture isformed by adding, in step 340, the output of subtractor 320 and theoutput of quantisation and transformation 310, and inverse transformingand inverse quantising the result in step 350. The reconstructed pictureis stored in Picture Store 360. The result is that the reconstructedpicture is simply the quantised source picture, and is independent ofthe motion compensated prediction. Hence a given source picture can bereconstructed identically when predicted from different referencepictures, and hence drift free switching is enabled. The motioncompensated prediction is not irrelevant, as it reduces the entropy ofthe signal to be variable length encoded and hence reduces the number ofbits produced by encoding a picture.

Access pictures are also coded as Quantised-Source pictures, with anidentical selection of coding modes, intra or inter, and quantiserchoice, as the linking picture. This ensures that the linking picturereconstructs identically to the simultaneous access picture in thedestination play stream.

The number of bits required to encode the linking pictures is determinedby the encoding of the corresponding access picture. The number of bitsused to encode the access picture depends on how the quantisation isperformed, but in general is more than the number of bits used to encodePredicted pictures and less than the number of bits used to encode Intrapictures. This is because encoding is more efficient than intra encodingdue to the use of prediction, but not as efficient as normal predictiondue to the quantisation of the prediction error. Hence the use ofQuantised-Source pictures allows drift free switching but at the expenseof less efficient encoding of the play stream.

Quantised-Source pictures are encoded with the same H.263 syntax aspredicted pictures, with the exception that they are distinguished frompredicted pictures by setting the first three bits of MPPTYPE to thereserved value of “110”.

The periodic encoding of Quantised-Source pictures can cause a beatingeffect in stationary areas of pictures. This is explained as follows. Innormal predictive coding, stationary areas of the picture which havealready been encoded as a reasonable representation of the sourcepicture are not modified. In the encoding of such areas inQuantised-Source pictures, the prediction must be quantised, and if donewith the quantiser index used for non-stationary areas of the picture,makes the region change, possibly making it worse, but in any case,changing it. This changing is the beating effect.

This is overcome by noting that when the prediction for an area of thepicture provides a good enough representation of the source, there is noneed to transmit information, and hence change the area So when anaccess picture is encoded as a Quantised-Source picture, a test isperformed to determine whether information about the area would havebeen transmitted if the picture had been encoded as a Predicted picturerather than a Quantised-Source picture. If no information would havebeen transmitted, the quantiser index used by the quantisation of steps300 and 310 and inverse quantisation of step 350 is set to a smallvalue, the output of subtractor 320, commonly known as the predictionerror, is set to zero, thus this area of the newly reconstructed pictureis equal to the corresponding area of the previous reconstructed picturequantised with a fine quantiser. In H.263 and other standards, the rangeof quantiser index is from 1 (fine) to 31 (coarse). By referring to asmall index, a value typically of 8 or less is meant. This minimisesunnecessary changes to the reconstructed picture while minimising theamount of information that must be transmitted. There will however be acost in bit rate in the corresponding linking picture, where theprediction error is unlikely to be zero, but the same fine quantisermust be used.

FIG. 4 is a schematic diagram of a client-server architecture suitablefor use in the system of FIG. 1.

The client 40 includes a network buffer 130, a decoding buffer 41 and adecoder 42. The server 10 includes circular buffers 70, 80, 90 asdiscussed above, and a packet transmitter 100 and network buffer 120 foreach client.

The client 40 keeps the server 10 informed of the amount of informationin its decoding buffer 41 and the rate at which it is receiving data.The server 10 uses this information to determine when to switch betweenplay streams. For example, when the client 40 has accumulated more thana threshold of data, say 15 seconds of data in its decoding buffer 41and the client 40 is receiving at a rate greater than or equal to theencoding rate of the next higher play stream in the hierarchy, theserver 10 can switch the client's packet transmitter 100 to the nexthigher slay stream at the next linking picture.

Similarly, when the amount of data accumulated by the client 40 in itsdecoding buffer 41 falls to less than a threshold, the server 10 canswitch the client's packet transmitter 100 to the next lower play streamat the next linking picture.

The overall effect is that the transmission rate varies in anetwork-friendly fashion according to the state of congestion in thenetwork, but due to the accumulation of data in the client's decodingbuffer 41, the user perceives no change in quality as a result of shortterm changes in transmission rate. Longer term changes in transmissionrate are handled by switching to a stream with a different encodingrate, to allow increased quality when the network allows it, and toreduce quality, without stalling presentation or presenting corruptedmedia to the user, when the network throughput drops.

The decoding buffer 41 at the client is used to reduce the impact ofnetwork performance variations on the quality of media presented to theuser. The network characteristics that the buffer is designed to handlefall into three categories: packet jitter, packet loss and variablethroughput. In practice these three network characteristics are notindependent, all being associated with network congestion, and in thecase of mobile networks, with degradation at the physical layer.

By de-coupling the transmission fate from the media encoding rate, theclient's decoding buffer 41 can be filled when network conditions arefavourable, to provide resilience for times when network conditions arenot so good.

The accumulation of tens of seconds of data in the decoding buffer 41,allows packet jitter (delay variations) of the same magnitude to bemasked from the user. In practice this masks all packet jitter, aslarger amounts of jitter are better classified as temporary connectiondrop-outs, which are handled by the error recovery process describedbelow.

By accumulating data in the decoding buffer 41, time is available forthe retransmission of lost packets before they are needed for decoding.Again, by dimensioning the decoder buffer 41 to contain more data thansome multiple of the round trip delay, there is time for a small numberof retransmission attempts to recover from packet loss. This allowsrecovery from most instances of packet loss without affecting decodedmedia quality, and makes the connection semi-reliable.

Finally, again by accumulating data in the decoding buffer 41, theclient 40 can sustain consistent media quality for some time when thereceiving bit rate is less than the encoding bit rate, and for some timewhen the receiving rate has dropped to zero.

As the data is streamed to the client 40 at a rate independent of theencoding rate, and buffered in the decoding buffer 41, it is necessaryfor decoding of data to be correctly timed, rather than simply to decodeand present as fast as possible. Timestamps are used for this purpose,as well as for the synchronisation of audio and video.

Due to network variations, the amount of data in the client's decodingbuffer 41, measured in bytes, may vary with time. In addition, theamount of data in the decoding buffer 41, measured in terms of thelength of media presentation time it represents, would also vary withtime. This has implications for streaming of live content: it is notpossible to build up data in the decoding buffer 41 if the first datasent to the client 40 is sent with minimal delay from the time it wascaptured and encoded. Hence, the first data that is sent to the client40 must be old data, that is, data representing events that took placesome time before the client 40 connected to the server 10. Then as thedecoding buffer 41 fills, the most recent data in it becomes more andmore recent, while the media presented to the user remains at a constantdelay from the actual time of occurrence.

The server buffers encoded data in its circular buffers 70, 80, 90, fora constant period of time after encoding so that when a client 40connects to the server 10, ‘old’ data is available for streaming to theclient 40. As the client's decoding buffer 41 fills, the reading pointsfrom the circular buffers 70, 80, 90 get nearer to the newest data inthese buffers.

The optimal sizing of the circular buffers 70, 80, 90, and the clientdecoding buffer 41, is preferably such that each can contain the sameamount of data, measured in terms of the media presentation time itrepresents.

The network buffers 120, 130 respectively in the server 10 and client 40are used by a transport protocol implementing the semi-reliable dataconnection. Typically, data is retained in the server's network buffer120 until it, and all earlier data, have been acknowledged to have beenreceived at the client 40. Similarly, data would be removed from theclient's network buffer 130 when it, and all earlier data have beensuccessfully received and passed to the decoding buffer 41.Consequently, the server 10, by knowing the data that remains in its ownnetwork buffer 120, knows what data has been successfully received bythe client 40, within bounds given by the uni-directional transmissiondelay.

This implies that no feedback from client 40 to server 10, beyond thatneeded by the transport protocol itself, is needed for the server 10 toknow how much data has been received by the client 40, so that it canmake decisions about switching between play streams.

The presence of an accumulation of data in the client's decoding buffer41 provides resilience to a number of network impairments, such asjitter, packet loss and variable throughput. Clearly, it is not possibleto recover from all network impairments unless the decoding buffer 41 isdimensioned to contain the whole media content and presentation isdelayed until all data is received. As this case is not streaming, butdownloading, a strategy to recover from serious network impairments isneeded.

At times when the network throughput drops to a level below the encodingrate of the lowest rate play stream for a considerable length of time,the amount of data in the decoding buffer 41 will reduce and willeventually become zero. At this time, presentation to the user willstop. However, circular buffer filling will continue at the server 10.Consequently, when the network recovers to a state in which transmissionof the lowest rate play stream is again possible, the next data requiredby the client 40 will most likely not be in the server's circular buffer70, 80, 90, as it would have been overwritten by more recent data.

To recover from this situation, the server 10 must restart streaming asif a new connection had been made from the client: it must find a pointin the intra stream, and start streaming from it, and then switchthrough the linking stream into the lowest rate play stream. The effecton the user will be the loss of media from the time that the decodingbuffer 41 became empty to the time when the server starts to send theintra stream.

The server 10 will be aware of the client's decoding buffer 41 becomingempty as it is aware of when the client started to decode and of howmuch data has been successfully received. It will therefore be able torestart at an intra stream picture without the need for a specificmessage from the client. However, to provide resilience to the system,for example to recover from the effect of different clock speeds in theserver and the client, a control message is sent from the client 40 tothe server 10 in this situation.

In principle, streaming from file is identical to live streaming. Inpractice, it is somewhat simpler. There is no need for Circular Buffers70, 80, 90 as data can be read from file as and when needed. The server10 however uses the same techniques to fill up the decoding buffer 41 atthe client 40 and to switch between play streams. In the case of thedecoding buffer 41 becoming empty, there is no need to restart at alater point in the content with an intra stream picture, as presentationcan resume when the network throughput again becomes sufficient: theuser simply perceives a period in which no media is presented.

Trick modes, such as fast forward, fast reverse and random access,become possible by use of the intra stream.

By writing ‘old’ data in the circular buffers 70, 80, 90 to file justbefore being overwritten, the problem described above of the decodingbuffer 41 becoming empty, and the user missing content until recoverywith an intra stream picture occurs, can be avoided, as data forstreaming to the client will always be available: it will have to beread from file rather than from the circular buffers 70, 80, 90.

Such functionality would also allow a client to pause the presentedmedia for an indefinite period of time, and continue streamingafterwards. It would also allow the user to fast forward after such apause to catch up with the live stream.

An implementation of the transport protocol tested in the abovementioned client-server architecture is based on the ISO TCP transportprotocol TPKT, which is described in detail in RFC-2126 by Y. Pouffary,“ISO Transport Service on top of TCP (ITOT)”.

The standard TPKT protocol defines a header illustrated in FIG. 5 a,followed by a payload. The packet length indicates the combined lengthof header and payload in octets.

In the implementation used for the present invention, TPKT is extendedto have a header, an example of which is illustrated in FIG. 5 b,followed by a payload. The packet length indicates the combined lengthof header, timestamp if present, and payload in octets. T is a bit thatindicates whether the timestamp is present, and M is a bit thatindicates whether the payload contains audio or video information.

As stated above, timestamps are required for the correct timing ofdecoding of data. Information embedded in packet headers include thelength of the packet, a timestamp for the data in the packet, and astream identifier.

The stream identifier is provided to allow audio and video to bemultiplexed into a single TCP connection. This is to ensuresynchronisation of audio and video transmission. If separate TCPconnections are used, it is possible that they will respond slightlydifferently to network characteristics and will achieve differentthroughputs, which would result eventually in vastly different amountsof data in the client's decoding buffers, measured in terms ofpresentation time. Although these differences could be managed, theissue is totally avoided by using a single TCP connection andmultiplexing audio and video with the same presentation time inneighbouring packets. In fact, adding audio to a video only systemsimply requires the sending of audio packets at the same time as theassociated video: no further control is necessary.

The server 10 attempts to send packets as quickly as possible.Initially, a number of packets are sent back-to-back regardless of thenetwork capacity, as they are simply building up in the server's networkbuffer 120. When the network buffer 120 becomes full, the rate at whichpackets can be sent to the network buffer 120 matches the rate oftransmission over the network, with the transmission process beinglimited by blocking calls to the socket send function.

The transmission rate is also limited when the amount of data bufferedat the client reaches a threshold, for example 30 seconds. When theclient's decoding buffer 41 has this much data, the server 10 restrictsthe transmission rate to maintain this level of fullness.

Network throughput is estimated by counting bytes that have been sent tothe network buffer 120, subtracting from this the size of the networkbuffer, and dividing by the time since the start of transmission.Shorter term estimates of network throughput are calculated using twocounts of bytes transmitted and two measures of the time taken to sendthem, calculating the throughput from one pair, and switching betweenthen periodically, resetting the pair no longer being used to zero. Forexample, if resetting occurs every 200 seconds, the network throughputis estimated over a period that varies from 200 seconds immediatelyafter resetting to 40 seconds just before resetting again.

This technique works satisfactorily provided the server 10 is attemptingto stream as quickly as possible. But as mentioned above, when theamount of data in the decoding buffer 41 exceeds a threshold, the server10 restricts its transmission rate to maintain a constant buffer fill.In this case, the network throughput would be estimated as the encodingbit rate of the current play stream. When in this state, the network maybe capable of transmitting a higher rate play stream than the onecurrently being streamed, but the server 10 does not switch because itcan not make a true estimate of the network throughput because of itsown rate limiting. To escape from this state, the server willperiodically ignore the client decoding buffer fullness threshold, andstream at full rate for a given period of time or given amount of data.It records the number of bytes sent to the network buffer 120 and thetime taken, starting when the network buffer 120 becomes full, asdetected by a blocking call to the send function. It then estimates theachievable throughput, and uses that to determine whether to switch to ahigher rate play stream.

As stated earlier, by knowing the data held in its network buffer i20,the server 10 implicitly knows which data has been received by theclient 40 and delivered to its decoding buffer 41. This information canthen be used to determine when to switch between play streams, and whento invoke the error recovery procedures. However, visibility of thecontents and fullness of the server's network buffer 120 in most socketimplementations is not supported. In order to monitor the contents ofthe network buffer 120, a mirror buffer 120 a is implemented. The mirrorbuffer 120 a does not store the actual data sent to the network buffer120, but instead stores only the number of bytes sent and the timestampof the data. Knowing the size of the network buffer 120, and assuming itis always full, the server 10 has access to the timestamp of the oldestdata in the network buffer 120 via the mirror buffer 120 a, which isapproximately the same as the timestamp of the newest data in theclient's decoding buffer 41.

In testing, it has been found that the assumption that the networkbuffer 120 at the server 10 is always full is correct at most times.This is because the transmission process is controlled to send asquickly as possible to the network buffer 120. If the network buffer 120becomes less than full, the effect is to underestimate the amount ofdata at the client 40, which in most cases is safe, as the major problemis seen as exhaustion of data at the client 40 rather than overflow. Inpractice, the decoding buffer 41 can be dimensioned to be larger thanthe largest amount of data it needs to store. In any case, if thedecoding buffer 41 becomes full the client 40 stops reading from thenetwork buffer 130 which in turn stops the server network buffer 120from emptying and transmission stops.

To determine the exact amount of data in the client's decoding buffer41, the server also needs to know the timestamp of the data packet thatthe client is currently decoding and presenting. The server 10calculates this using two assumptions: firstly that the client 40 startsdecoding immediately after the server 10 sends the first packet; andsecondly, that the client's clock does not drift significantly from theserver's clock in the duration of streaming.

In practice both assumptions have been found to be valid. The client 40is designed to start decoding immediately on receipt of data, and so anyerror on the server's estimated presentation time would result in anunderestimate for the amount of data in the decoding buffer 41, which asexplained above is not a problem. Drift between the client's andserver's clocks during a typical streaming session is most likely to benegligible compared to the amounts of data being buffered. For example,with a difference of 100 parts per million, it would take 10000 seconds,or nearly three hours, for a drift of one second to occur. In the rarecase of a large amount of drift accumulating, the client 40 can warn theserver 10 by use of a control message, such as the one described earlierthat is sent for decoding buffer underflow.

The server 10 initially streams the play stream with the lowest bitrate, to allow the client 40 to decode and present media to the userimmediately while also building up the level of data in the decodingbuffer 41 to provide resilience to network impairments. If the networkhas sufficient capacity to support transmission of a higher rate playstream, the server 10 should, at an appropriate moment in time, switchto streaming a higher rate play stream.

There are many possible strategies that could be used to determine whento switch to a higher rate play stream. Preferably, the client 40 shouldhave sufficient data in its decoding buffer 41 to be able to continuedecoding and presenting media for a predetermined period of time, say 15seconds. It is also preferred that network throughput that has beenachieved in the recent past, measured over, say, the most recent 60seconds, should be sufficient to sustain streaming of the play stream tobe switched to indefinitely; that is, the recently achieved networkthroughput rate should be greater than or equal to the bit rate of theplay stream. The aim is to avoid frequent switching between streams asthis can be more annoying to the user than constant quality at the lowerrate.

In order to achieve this aim, it is preferred that the switching downdecision includes hysteresis relative to the switching up decision. Forexample, switching down to the next lower bit rate play stream could betriggered when the client 40 no longer has sufficient data in itsdecoding buffer 41 to be able to continue decoding and presenting mediafor a specified period of time, say 8 seconds. In the case of aconfiguration with three or more play streams, and the currentlystreamed play stream being the third or even higher rate play stream,this strategy does not result in an immediate drop to the bottom of thehierarchy, as access pictures only occur periodically, and it is hopedthat the decoding buffer fullness would recover after a first switchdown so that a second switch down would not be necessary.

FIGS. 6 a-6 c are schematic diagrams of aspects of a data structure forstoring an audio-visual data source suitable for use in the presentinvention.

The main data structure shown in FIG. 6 a permits the storage in asingle file of multiple audio play streams, an Intra video stream, andmultiple video Play and Switching streams.

As the audio visual data source created and used in the presentinvention has a number of encoded streams that could be transmitted atany one time to a client, storage in a conventional sequential file isnot possible. For example, in the case of video, a particular sourcepicture may be encoded in each play stream, and may also be encoded inthe Intra stream and some or all of the Switching streams.

The file contains a data structure, an example of which is illustratedin FIG. 6 a, followed by stream data. The data structure includes aheader 600 containing information about the number and type of streams(audio, video, switching etc). For the first and last instances of eachtype of stream it also includes pointers 610-680 (expressed as offsetsfrom the beginning of the file) to the header for the respective stream.

Each pointer 620-680 points to a stream data structure which includes astream header 700, containing a pointer 710 to the next stream header ofthe same type, a pointer 720, 730 to the first and last packets of thestream respectively. Each stream type uses a specific stream headertype, however certain elements are common to all stream header types: astream identification number 705, a pointer 710 to the next streamheader of the same type and pointers 720, 730 to the first and lastpackets of the stream respectively. An example stream header containingonly these common elements is illustrated in FIG. 6 b. Play and audiostream headers additionally contain the bit rate at which the stream wasencoded. Switching stream headers contain the stream identifiers of theplay streams from and to which the Switching stream enables switching.

Each stream consists of a sequence of packets, each represented by apacket data structure, an example of which is illustrated in FIG. 6 c.Each packet data structure includes a packet header 800 and a payload810. The header includes data including a pointer 801 to the next packetin the stream, a timestamp 802, a packet sequence number 803, packetsize 804, and a frame number 805 (i.e. the sequence number of the videopicture or audio frame which the packet, perhaps together with otherpackets, represents). Switching packets additionally contain thesequence numbers of packets in from- and to- Play streams between whichthey allow bit rate switching to take place. The switch stream packetheader effectively defines a switching point and contains the sequencenumber of the last packet to be played from the “from” stream beforeswitching and the first to be played from the “to” stream afterswitching. Sequence numbers begin at 0, and are never negative. The useof pointers to assist in navigation between streams when switching ispossible, although this approach has not been followed in thisparticular embodiment.

The pointers to the last stream data structure and the last packet areuseful when appending to a file, as they provide immediate access to thepoints at which the file must be extended, without the need to searchthrough the whole file.

The complexity of the data structure is a consequence of packets frompotentially many streams being interleaved, and of the need to supportswitching and recovery. Navigation from packet to packet is necessarilyby pointers since, in general, packets which are consecutive within astream will not be stored contiguously within the file. Writing ofswitching and recovery packets requires that precise details of sourceand destination packets be recorded. Switching between streams duringplayback requires firstly the identification of the next availableswitching packet, followed by playback of the remaining packets from the“from” stream, playback of the switching packets, then the playback ofpackets from the “to” stream from the appropriate point. Furthermorethere must be no appreciable delay when switching between streams.

In tests, both file-based and live streaming scenarios were investigatedusing the BTCellnet™ GPRS network. A desktop Pentium PC was used to runthe encoder and Server. The client was a Compaq iPaq™ connected with viaan infra-red link to a Motorola Timeport™ GPRS mobile telephone.

In a video-only configuration, two switching streams were used, with bitrates of 6 kbit/s and 12 kbit/s.

The system performed as expected. Transmission starts with the intrastream and then switches to the 6 kbit/s play stream, where it stays forsome time, accumulating data in the client as a result of actuallytransmitting faster than 6 kbit/s. Then when sufficient data has beenaccumulated, and the short term average receiving rate is more than 12kbit/s, it switches to the higher rate play stream.

At times during a lengthy session, occasional switches back to the lowerrate play stream occur as a result of reduced network throughput. Andvery rarely, media presentation is interrupted because of a significantperiod during which the network could not deliver data to the client.

The overall effect is for most sessions, the user can view continuousmedia presentation, with occasional changes in quality, but nodistortions of the type usually associated with bit errors and packetloss. Only very rarely are complete pauses in media presentationobserved as a result of severe network impairments and loss ofthroughput.

1. A data streaming system comprising a server (10) arranged to streamone of a plurality of encoded data streams to a client (40, 50, 60),each of the plurality of data streams being an independentrepresentation of a common data source encoded at a different resolutionto the other of the plurality of data streams, the server (10)comprising a transmitter (100) and a first buffer (120), the transmitter(100) being arranged to transmit data packets of the encoded data streamto the client (40, 50, 60) via the first buffer (120), wherein thetransmitter (100) is arranged to monitor the content of the first buffer(120) and switch to transmit another of the plurality of data streams inthe event that predetermined criteria are detected from the first buffer(120).
 2. A system according to claim 1, wherein the transmitter (100)is arranged to determine the amount of data buffered at the client (40,50, 60) from the content of the first buffer (120), wherein thepredetermined criteria include a predetermined level of data determinedto be buffered at the client.
 3. A system according to claim 2, whereina data packet is removed from the first buffer (120) uponacknowledgement by the client (40, 50, 60) of receipt of the packet. 4.A system according to claim 3, wherein the transmitter (100) is arrangedto determine the amount of data buffered at the client (40, 50, 60) independence on the latest data packet removed from the first buffer (120)and on an estimation of number of packets decoded by the client (40, 50,60).
 5. A system according to claim 1, wherein the first buffer (120)includes a mirror buffer (120 a) storing data on packets in the firstbuffer (120), the transmitter (100) being arranged to monitor thecontent of the first buffer (120) using the data in the mirror buffer(120A).
 6. A system according to claim 1, wherein data packets aretransmitted to the client (40, 50, 60) using an extended TPKT protocol,the data packets including a header containing a decoding timestamp anda data stream identifier.
 7. A system according to claim 1, furthercomprising a plurality of transmitters (100), each communicating with arespective client (40, 50, 60) via a respective first buffer (120) totransmit one of the plurality of data streams determined in dependenceon respective predetermined criteria.
 8. A system according to claim 1,wherein the data stream is encoded video data.
 9. A system according toclaim 8, wherein the transmitter (100) is arranged to multiplex audiopackets and video packets within the transmission of data packets.
 10. Asystem according to claim 9, wherein neighbouring audio and videopackets represent audio and video information that is intended forrepresentation at substantially the same time.
 11. A system according toclaim 1, wherein the data stream is encoded audio data.
 12. A systemaccording to claim 1, wherein the resolution is an encoding bit rate ofthe data.
 13. A system according to claim 1, wherein the server (10)includes an encoder (20) arranged to accept a data feed and encode thedata feed into the plurality of encoded data streams.
 14. A systemaccording to claim 13, further comprising a plurality of buffers (70,80, 90), wherein the encoder (20) is arranged to output each encodeddata stream into a respective one of the plurality of buffers (70, 80,90), the transmitter (100) being arranged to obtain data packets for arespective data stream from its respective one of the plurality ofbuffers.
 15. A system according to claim 1, wherein the server (10)includes a file source (30) storing the plurality of encoded datastreams.
 16. A data streaming system comprising a client and a server,the server (10) being arranged to stream one of a plurality of encodeddata streams to the client (40, 50, 60), each of the plurality of datastreams being an independent representation of a common data sourceencoded at a different resolution to the other of the plurality of datastreams, the server (10) comprising a transmitter (100) and a firstbuffer (120) and the client (40, 50, 60) including a receiving buffer(130), wherein the transmitter (100) is arranged to transmit datapackets of the encoded data stream to the client (40, 50, 60) via thefirst buffer (120), wherein the client (40, 50, 60) is arranged to storereceived data packets in the receiving buffer (130) and to acknowledgereceipt to the server (10), wherein the transmitter (100) is arranged todelete packets from the first buffer (120) when an acknowledgementreceipt is received, the transmitter (100) being arranged to switch toanother of the plurality of data streams in the event that predeterminedcriteria are satisfied, the predetermined criteria comprising analysison content of the first buffer (120).
 17. A system according to claim16, wherein the packets include packet sequence data, the client (40,50, 60) being arranged to request retransmission of non-received packetsbased on the sequence data, the server (10) being arranged to retransmita packet from the first buffer (120) upon receipt of a retransmissionrequest.
 18. A method of streaming one of a plurality of encoded datastreams to a client, each of the plurality of data streams being anindependent representation of a common data source encoded at adifferent resolution to the other of the plurality of data streams, themethod comprising the steps of: transmitting data packets of the encodeddata stream to the client via a first buffer; monitoring the content ofthe first buffer; and, switching to transmit another of the plurality ofdata streams in the event that predetermined criteria are detected fromthe first buffer.
 19. A method according to claim 18, wherein theplurality of data streams are each encoded at a different bit rate, themethod further comprising the step of initially transmitting datapackets of the lowest bit rate data stream.
 20. A method according toclaim 18, wherein the predetermined criteria includes an amount of datadetermined to be buffered at client.
 21. A method according to claim 18,wherein the predetermined criteria include one or more networkthroughput thresholds.
 22. A method according to claim 21, whereinnetwork throughput is calculated by the steps of: counting the number ofbytes passed to the first buffer; subtracting the counted number ofbytes from the size of the first buffer; and, dividing the result by thetime since the start of transmission.
 23. A method according to claim22, further comprising the step of measuring network throughput overmore than one interval to determine throughput variation.
 24. A methodaccording to claim 22, wherein the predetermined criteria includedetermination of network throughput sufficient to sustain the other ofthe plurality of the data streams.
 25. A method according to claim 22,further comprising the step transmitting data at a maximum rateirrespective of an amount of data buffered at the client, wherein thepredetermined criteria include network throughput determined at themaximum rate.
 26. A method according to claim 18, wherein the datastreams are encoded as a series of pictures predictively encoded independence on the previous pictures in the data stream, the data streamsincluding quantised source access pictures interspersed at predeterminedperiods in the picture series, wherein the method of encoding thequantised source access pictures including the steps of : encodingpicture as a predicted picture; and, if no information about an area ofa picture is indicated in the encoded predicted picture, setting thequantiser index to a fine quantisation value when encoding as aquantised source access picture.
 27. A computer program comprisingcomputer program code means for executing the steps claim 17 when run ona computer.
 28. A computer program as claimed in claim 27 embodied on acomputer readable medium.